Subject: APPN MIB review comments

From: Robert Clouston <[email-masked]>
Date: Sun, 21 May 95 23:44:20 EDT

Following are my comments on the APPN MIB.  One of my major concerns is the
size of the MIB, so I've tried to identify redundant or meaningless
information in this MIB, or information that belongs in other MIBs.

1) ibmappnGeneralInfoAndCaps
 a) ibmappnNodeBlockNum description is incorrect, this is configurable in some
 product.  Change this globally for other BlockNum variables

 b) I see value in leaving HprSup and HprTrans in this table to tell that a
 node is HPR capable but everything else is specific to HPR implementations
 and should be in the HPR MIB and not here.
 
2) ibmappnNode: merge NnTreeUpdate into NnTreeCache as a value of IncrUpdate

3) ibmappnNodePortTable 
   a) index by ifIndex so manager can take advantage of information from 
   other MIBs.  There is probably a lot of overlap with other MIBs so we
   investigate removing some of the other variables.  This whole port section
   needs a lot of work
   
   b) The trace stuff looks pretty product-specific and will probably be tough
   to keep current.  How about using the SNA NAU MIB generic trace method?

4) ibmappnNodeLsEntry
   a) add partner node type (LEN|EN|NN|unknown)
 
   b) CpName may not be known if link inactive, so SIZE should be (0..17)

   c) TgNum: can't 0 (instead of 256) indicate unknown (not negotiated)?

   d) LimResource description is incorrect. LINK goes inactive, not TG 
    (TG should stay operative in the topo DB).  There are other descriptions 
    in this table that refer to TG and should refer to the link station 
    instead.

   e) what does the LsMigration mean (in what respect are the partners
   down-level? 
   
   f) add CpCpSessAct field to indicate actual status of CP-CP sessions (other
   field indicates only support)

   g) Xid counters (bytes/frames in/out) seem like overkill, can they be
   removed?
   
   h) everything beyond LsDestHprTrans belongs in the HPR MIB.
   
   i) LsIpTable, LsDlsTable, LsTrTable should be removed
   
   j) add activateableOnDemand variable 

5) ibmappnNodeLsStatusTable
   a) same comments regarding CpName and TgNum as LsEntry
 
   b) NodeID: use BlockNum & IdNum format used everywhere else
   
   c) Why so many sense codes?  Just one is needed.  Some products may 
   internally log a sense code that says (basically) "XID failed because
   other side sent CV22" but that adds no value.  XidByte/Bit InError is 
   also reflected in the sense code when relevant and can be removed.
   
6) ibmappnSnmp performance information is useless and should be removed.
   This needs to be done at the agent level, not at a subagent, to tell 
   anything worthwhile.

7) ibmappnNnTopo
  
  a) MaxNodes-some implementations don't have a maximum, 0 should mean no max
  
  b) CurNumNodes - description should reflect that the alert isn't sent if
  MaxNodes = 0
  
  c) InTdus, OutTdus - what value does this have?  Justify it or remove it.
  
  d) Node/TG LowRsns - description is  bad, low RSNs do not "result when TDUs
  are broadcast to all adjacent nodes.", there is more to explain
  about this. It usually happens when an NN reconnects or there are
  rapid updates about a resoure and there is a propagation delay of TDUs
  in the network, or error conditions, like the same name defined twice
     
  e) Node/TgTimerUpdates - remove these, they have no value.  Heartbeat TDUs
  aren't even sent for TGs.
  
  f) Consider adding a counter for high RSNs received for local nodes & TGs.  
  This may indicate TDU war since the local node should generate highest RSN 
  for its own resources
  
  g) TotalRouteCalcs and TotalRouteRejs isn't very useful and can be summed
  up from the COS variables if for some reason they are interesting.  Remove
  them here.
  
8) ibmappnNNAdjNodeTable
  This whole table can be removed by adding the node type on the LS entry
  as listed above.  That table has the adjName and CpCpSessStatus.
  The other fields aren't interesting, especially the lastFrsn fields
  
9)ibmappnNnTopology table
  a) add garbage collect bit for both nodes and TGs to indicate a node or
  TG marked for garbage collection (new architecture)
    
  b) NnTgDlcData, I think the architecture holds up to 16 bytes for this
  field in the cv46 sf 82
  
  c) NNTgCpCpSession - 2 fields for this now (support and status)
  
  d) NNTgEffCap consider using 0..255 encoded value
  
  e) add the subarea number
  
  f) check for any other new fields in CV44-47
  
10) ibmappnNNTopologyFR table
  a) FrEntry description is incorrect, FRSN is also used to index table.
  
  b) for both NN and TG FR table, to avoid dual maintainance and reduce
  MIB size, remove all but the fields needed to index the non-FRSN tables.
  Perhaps also include just a couple key fields like TgFROperational since that
  is the most likely one to change and is also the most important. 

11) ibmappnLocalGeneral, ibmappnLocalNnSpecific
  Remove these variables, they are duplicates of ibmappnGeneralInfoAndCaps
  and ibmappnNnUniqueInfoAndCaps,
  The only one that I don't see duplicated is ChainSupport and that should
  be added in NnUnique.
  
12) ibmappnLocalTGTable
  Most is duplicated in the LS table; there are two useful things here:
  1)the TgOperational variable, which can indicate an activateable on demand
  like that is available for routing even if the link is inactve.  This can
  be added to the LS table as I suggested above;
  2) this is the only place I see to get virtual node information defined for
  the local EN (NN's VRN can be retrieved from NN topo).  Just make this the 
  virtual node def table, and include everything but the TgDestVirtual
  indicator.
  
13) ibmappnLocalEnTable
  By adding the node type to the LS table we can remove this whole table.
  The only missing field is time left and that really doesn't apply to ENs 
  because they don't send heartbeat TDUs, so time left makes no sense.
  
14) ibmappnLocalEnTgTable
  This should only include TGs registered by the EN.  It should not include
  the "reverse" TG created by the NN on behalf of the EN since the NN is
  just guessing at what the EN has defined for the TG, and the ENs definition
  will be used in route calculation when the EN sends TG vectors in the
  LOCATE/CDINIT.
   
15) ibmappnDir
  a) It would be nice to have a method like FRSN to receive updates; the cache
  normally has most recently used entries at the front so with a FRSN
  scheme you could discover newly added entries; but you need a way to
  discover deleted entries.  Maybe an index that only gets incremented as
  an entry is added to the cache, and not just when an entry is moved to
  front.  This would mean a second table like the NNFR table for topology.
  
  b) May want to count # of deleted cache entries due to cache overflow, so
  you know whether you need to increase cache size if that is configurable.
  
  c) ServerName-- unassociated ENs should return blank server instead of
  own name.  Otherwise a remote (non-domain) EN looks like an NN if it
  doesn't have an NN server for some reason.
  
  d) LuLocation--describe categories; where do adjacent LEN LUs fit in?
  
  e) Type -- description is bad
   Home is only local LUs or domain LENs (configured LUs may include
   partner LU location for loading the cache)
   Cache may have been found via a define partner LU location (sysdef),
   or discovered from a central directory server as well as broadcast
  
  f) Consider adding table to track outstanding Locates (both local and
  remotely initiated to identify "hung" locates.  Might be tough to do
  in a MIB but this was brought up as a problem in the last AIW.
   
16) ibmappnCos
  a)NodeRowEntry description bad; it identifies the COS row, which is
  more explicit than just to "insure a unique index".  It needs to be
  clear that these rows are in order of ascending weight.

  b) ibmappnCosNodeRowName should go away and the 
  ibmappnCosName should be an index instead.  

  c) I'm confused about the whole indexing scheme so maybe I don't know
  what the purpose is.  I think it should be:
  CosTable indexed by COS Name
  CosNodeRowTable indexed by CosName and NodeRowIndex
  CosTgRowTable indexed by COS Name and TG Row

  d) there is no requirement for the same number of node and TG rows.
  Because the NodeRowIndex and TgRowIndex reference each other in the
  description this seems implied.  These indices have nothing to do with
  each other so remove the cross-reference in the description.
  
  e) Node/TG RowWgt--This should just be an integer.  Display
  string implies a formula but I don't think any implementation is that
  sadistic.  If they are it can be a product-unique extension.
  
  f) TgRowEffCap--suggest using 0..255 encoded value
     
17) ibmappnIsIn
  a) GlobeStatus, GlobeCtrStatus--which names may not be collected?
  
  b) TransPriority -- need enums for network, high, medium, low
  
  c) SessState--Is this a forced or normal inactivate on a set?  Is this
  MIB-legal to allow a write to only one of the enum types?
  
  d) SessStartTime description--Time is since when node came up?
  
  e) RtpTable belongs in the HPR MIB
  
18) APPC information
  I'm really really confused about this.  Isn't this what the APPC MIB is for?
  Get rid of all of this to the end of the document.      

19) Global comment:  use TruthValue instead of Yes/No enums